Hello @fl4via / @ropalka Could anyone of you review this? I am not familiar with the ContextManager and what this setGlobalDefault implies, thanks

Generally would be good to point why this change will affect outbound comm.(given comment above alone) @tadamski ^^

@tadamski @fl4via How is this tested?

Not so sure about this change. The Contextual Endpoint is used by all client code (Naming client, EJB client, Transaction client) to initiate connections from the client to a server. The wildfly-config.xml file is used to configure this contextual as well as the others that are available to the client side code (EJBClientContext, Discovery, AuthenticationContext, XnioWorker, ...). Generally, these various Contextuals are initialized statically by parsing the wildfly-config.xml file and setting a global default in the context manager, whether the client code is running on a standalone client or within a deployment on a server.

This change will cause the Contextual Endpoint to point to the Endpoint defined in the Remoting subsystem, and not the usual Contextual Endpoint initialized with wildfly-config.xml. The possible problems I see are:
(1) now to configure the client-side connection properties for any Wildfly client code in a deployment, we cannot use the wildfly-client.xml file and need to configure the client-side properties in the Remoting subsystem Endpoint configuration, which will have to be the same for all clients
(2) the XnioWorker instance will still be configured from wildfly-config.xml and not from within the Remoting subsystem, which is a bit confusing as the Endpoint and XnioWorker are so intimately related

It seems to me that configuring outbound connection establishment using wildfly-config.xml and configuring inbound connection establishment using the Remoting subsystem Endpoint works, as long as we can correctly get the configuration options to the Endpoint instances, which was a problem previously.

I'm also wondering about the role that remote outbound connections have to play in this scenario of a deployment using Wildfly client code to get off the server.

@dmlloyd WDYT about this PR proposal?

Generally I'm in favor of this idea. It's what I always wanted to do but didn't quite manage at the time.

To address (partially) @rachmatowicz's comments:

It is true that XNIO is more centrally configured compared to Remoting. This actually is by design though: it was always intended that one XNIO instance would support the needs of all networking I/O, and this has guided the design of XNIO from the beginning. So XNIO remains a foundational piece, whereas other things (like Remoting) are meant to be added atop it.

As for the loss of per-deployment client configuration, I agree this may end up being a problem in practice. But the solution to this problem is not general (e.g. to replicate just the Endpoint). The better approach would be to determine what configuration makes sense for individual deployments based on the underlying abstractions which are available and the needs of the user. Exposing every possible knob has always been a weakness of this architecture, not a strength. I'd say it's most prudent to address specific problems that are expected on a one-by-one basis, and to handle other problems as they arise, if they arise.

I'm putting the issue on hold, because of the ongoing discussion and the need to add tests before the PR is merged.

There has been no activity on this PR for 45 days. It will be auto-closed after 90 days.

There has been no activity on this PR for 90 days and it has been closed automatically.